The PHP 5 challenge

Thursday, May 10. 2007

During the month of PHP bugs several people changed their credo from: "there are no vulnerabilities in PHP" to "vulnerabilities in PHP are not important, just tighten your OS". Other claimed that you can not rely on safe_mode and that you can always use shell_exec() to execute everything on the system.

It is quite amusing how the "safe_mode is flawed by design" green card is nowadays used to deny the seriousness of local PHP vulnerabilities. Just because safe_mode was a bad idea this does not automatically made disable_function a bad idea. And yes disable_function is nearly always used. Admins forbid the usage of all kind of functions like ini_get(), phpinfo(), shell_exec(), popen(), ...

So here comes the challenge. Imagine a PHP 5.2.2 server with ALL builtin functions being disabled. The challenge is to write PHP code that executes any binary inside the /bin directory. According to all those (marketing) people who claim that executing any PHP code is equal to shell access and therefore local vulnerabilities in PHP are irrelevant, this should not be too hard.

Yeah well, I guess all those not yet brainwashed by the marketing departments have already realised that without access to ALL builtin functions it requires a local PHP vulnerability to achieve this otherwise impossible task and therefore I win anyway.

Update: Oh yes and if you think that your Apache is chrooted anyway, and therefore /bin is not reachable, then you can also win by breaking out of the chroot, like exploiting the kernel, with PHP code. Otherwise you could just admit that without local vulnerabilities in PHP it is simply not possible to call functions that do not exist (not loaded extensions or disable_function or the magic exploit_da_kernel() function).

Posted by Stefan Esser in Security, PHP at 16:11

Comments (13)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Gareth Heyes wrote (Link) ()

Hey Stefan your challenge was easy

echo '';
echo '';
echo 'Execute binary';
echo '';
echo '';
echo '';
echo '';
echo '';

#!/usr/bin/perl
system("ls");

This was a joke btw

posted on Thursday, May 10. 2007

#2 emil ()

what about the backticks?

posted on Thursday, May 10. 2007

#2.1 Stefan Esser wrote (Link) ()

The backticks are just an alias for shell_exec()
When shell_exec() is disabled backticks are also disabled.

posted on Thursday, May 10. 2007

#3 Ilia Alshanetsky wrote (Link) ()

If you have the ability to write to files from PHP in your homedir you can write the .qmail or .procmail and setup an e-mail filter, which will then execute a shell command of choice upon an arrival of an e-mail.

Some hosting companies also have a local cron.d directory for each user, writing a file in there will direct the cron or equivalent to execute a command of your choice.

posted on Thursday, May 10. 2007

#3.1 Stefan Esser wrote (Link) ()

First of all I wonder how you write to any file with file functions being disabled. And yes there are hosters that disable fwrite/fputs...

Secondly if you can write with your PHP script to .qmail or .procmail or some obscure cron directiory and this results in code execution, then you used a local vulnerability in the OS configuration. Therefore your example just proves my point.

Beside the fact that abusing holes in the OS configuration is not needed, because PHP has plenty of local vulnerabilities on its own.

To win this challenge you have to prove that it is a feature of PHP to execute a shell command directly when this is not allowed by the configuration.

posted on Thursday, May 10. 2007

#3.1.1 Ilia Alshanetsky wrote (Link) ()

Hosters that disable file operation functions are an exception not the rule. Many may run with open_basedir/safe_mode and command execution functions off, even ini* functions off, but I have not seen many systems where you cannot write to files.

Btw writing to files can be done by more then just fwrite/fputs

It an be done by sqlite_open, save* methods in DOM extensions, GD extension and many others.

Plus attacks don't always have to be code execution, denial of service maybe good enough. For example
or .

disable_functions will need to be complemented by a very heavy handed disable_classes as well to truly make PHP useless.

posted on Thursday, May 10. 2007

#3.1.1.1 Stefan Esser wrote (Link) ()

Ilia,

please stop arguing. You cannot win this discussion.

The disable_function configuration is safe. There is no design flaw in it, because removing functions I consider harmful, will work and there is no way to get them back through PHP code. The fact that you can forget to disable some functions because there is no real logic in PHP and everything can be done in 3 or 4 different ways is unrelated.

The PHP developers are currently travelling into a very wrong direction and I hope they wake up before it is to late. Stop blaming everything on others. What a lame excuse is it to say: Others have also local vulnerabilities, so ours are harmless.

Face it or not. PHP is so widespread because it was advertised for years to be easy installable, easy useable and that is is rather secure because you can easily disable all functions, extension, safe_mode, open_basedir.

PEOPLE USE disable_function BECAUSE IT IS ASSUMED TO BE SAFE, AND BECAUSE IT IS SAFE (WITHOUT THE LOCAL VULNERABILITIES)

It is really a pity that after having realised that there are tons of local vulnerabilitites in PHP that are caused by internal design flaws and cannot be simply fixed with a little buffer overflow fix here and there, the PHP developers give up and just declare these bugs as not harmful.

I really left the sinking ship (PHP Security Team) at the right moment.

BTW: For the record, it is not cool to disagree with me on security matters, it just proves how learn resistant PHP developers are.

posted on Friday, May 11. 2007

#3.1.1.2 Jason Frisvold wrote (Link) ()

Ilia,

It's not a matter of "oh, there are local vulnerabilities in other programs, so the ones in PHP don't matter" .. What if PHP was the only program on the box with a local vulnerability?

Better yet, what if the developers did work hard and close all known vulnerabilities? That would be a shining example in the OSS world and help to raise the bar for security.

As with the old saying, just because other products have security holes doesn't mean that this one has to.

And I believe Stefan focuses on PHP and the vulnerabilities therein because that's his particular area of expertise. I may not agree with the abrasiveness with which Stefan responds, but in most cases he's correct. I've found that a lot of security engineers tend to be abrasive when it comes to security only because that's the only way people listen..

Stefan, keep up the great work.. I think your contributions are ultimately helpful and will lead to a more stable, secure platform.

posted on Friday, May 11. 2007

#4 Nick ()

I'm curious what the sources are that you indirectly cite in this post. What marketing materials is this post a response to?

posted on Thursday, May 10. 2007

#5 elias ()

if you rely on disable_functions only, SplFileObject gives you read/write access.

but i guess you mean ALL functions and classes are disabled?

posted on Friday, May 11. 2007

#6 Punisher ()

Hi

In php language now exists combinations into the language(for example, a special method with a for loop with malicious variables), for make a buffer overflow?.

I think that if you don't have access to any function, a possibility is use language structures(loops, ifs, variables) for make a buffer overflow if exists a bug, or active functions... is it?.

posted on Thursday, May 17. 2007

#6.1 Stefan Esser wrote (Link) ()

Well something like this is needed

http://www.php-security.org/MOPB/MOPB-01-2007.html

but THAT trick will only work in PHP 4.

However even a solution with builtin classes that
does not use any function (because those are disabled)
is acceptable...

Reason: Most admins don't know how dangerous the builtin
classes can get... The PHP developers FAILED to document
the risk of the inbuilt classes in PHP 5.

posted on Thursday, May 17. 2007

#7 overdose ()

i think you know there are a lot of vulns with realloc() in php
but need to eat all the available ram and swap for exploit some heap overflow

posted on Thursday, May 24. 2007

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar